(navigation image)
Home American Libraries | Canadian Libraries | Universal Library | Community Texts | Project Gutenberg | Children's Library | Biodiversity Heritage Library | Additional Collections
Search: Advanced Search
Anonymous User (login or join us)
Upload
See other formats

Full text of "dec :: prism :: memos :: 850528 NONVAX"

To: Distribution From: Dave Cutler 

Date: 28 May 1985 pileep Bhandarkar 

1 Wayne Cardoza 

Dave Orbits 
Rich Witek 



Subject: Architecture Review 

A strategic effort has begun within the company to define a new 
architecture for the 1990s that will complement our current VAX/VMS 
offering . 

To this end, a small group has been chartered by engineering 
management to define and draft an architectural standard for this new 
family of machines. The intent is to run the architectural process as 
we did for the VAX, and to solicit and encourage various people to 
contribute. The architecture standard will be widely reviewed. 

Below is the initial set of goals and constraints the architectural 
group has set for the new architecture. We would like you to review 
these goals and provide feedback in the form of a written response. 



It is important to undertake this effort, and have the proper goalset. 

in the future, you will also be asked to review the architecture 
document. We welcome your input and comments. 

Assumptions 



The following major assumptions have been made for this architectural 
effort: 

1. There will be one, and only one, architecture across all 
implementations . 

2. The architecture is not restricted to be a RISC architecture. 
It is a non-VAX architecture that will be an upward extension 
of the VAX/VMS family. 

3. The aspects of VAX that make it hard to build fast machines 
quickly and easily will be changed. 

4. This is a "from scratch" effort. The VAX System Reference 
Manual%will be used as the starting point. 

5. This is' a strategic effort within the company. There is a 
high-level of commitment to implement this architecture and 
provide the necessary resources. 

6. An implementation may use microcode. (That is, there no 
constraint against the use of microcode.) 



10 



11 

Goals 



Page 2 

This design work is similar to the the VAX architectural 
effort; we are not going to produce anything stopgap. 

An architectural document will be produced as soon as 
possible. It will be reviewed by a larger group and then by 
the corporation. 

It is expected that it will take around three months to 
define the architecture. 

It is assumed that an operating system environment will be 
constructed that has a compatible file system, network, and 
user interface with VMS. It is also assumed that the system 
can be clustered with VMS. 

It is assumed that ULTRIX will be ported to this 
architecture. 



The major goals are: 

1. To minimize the software investment over time. 

2. To allow VMS layered products to be moved to the new 
architecture. 

3. To allow faster, more cost effective machines to be built. 

4. to allow shorter development cycles. 

5. To allow for parallelism in instruction execution. 

6. To allow for Symmetric Multiprocessing (SMP). 

7. To have a "pipelineable" orientation. 

8. To be "subsettable." 

9. To be the new corporate architecture for 1990s. 

10. To fix anticipated deficiencies and limitations in VAX, e.g., 
limited physical .and virtual address size. 

.11. To support the Digital I/O interconnect strategy. 

12. To provide floating point accuracy greater than or ■■ equal to 
VAX. 

13. To ensure that high-level language programs produce the same 
results as they would on a VAX. 



Page 3 



Non-Goals 



Non-goals are: 

1. To include VAX-compatibility mode. 

2. To support unibus/Qbus/Massbus peripherals. 

3. To translate VAX macrocode transparently and efficiently, 

Constraints 



The architecture is constrained by the following: 

1. It must support VAX-compatible data types. 

2. It must support VAX-compatible memory addressing (byte 
addressability) . 

3. It must be compatible with the way VAX handles interlocked 
I/O queues . 

4. It must be able to execute the same executable image on every 
implementation . 

5. It must provide at least twice the performance/cost of a 
particular VAX implementation, using the same technology. 

Posted: Tue 28-May-1985 15:03 PDST 
To : @ART 



+ + 

"digital! interoffice Memorandum 
+ + 

To: List Date: 30 May 1985 

From: Richard Grove 

Dept: Technical Languages 

DTN : 381-2082 Loc . : ZKO2-3/N30 

Enet: Orphan: :Grove 

File: RBG066 Rev.: 1 

Subj: DECwest Trip Report: Technical Summary 

CAUTION 

The NONVAX program discussed here is a major 
strategic undertaking; all information about the 
program is COMPANY CONFIDENTIAL. 

Please limit the distribution of this report. 

Many of the topics mentioned here are still under 
discussion and all will be subject to a 
wide-ranging formal corporate review. This report 
is a snapshot taken in mid-May. 



1 GENERAL 

This memo summarizes my visit to DECwest Engineering May 13-16. The 
purpose of my visit was to meet with Dave Cutler and Don MacLaren and 
to begin work on software architecture issues for the NONVAX family of 
high-performance machines. The meeting was very successful. There is 
a substantial consensus on technical issues and approaches. We 
outlined the software architecture documents that need to be produced 
and we started work on some of the technical content. We agreed on an 
informal process for getting more people involved in the technical 

work. 

The new architecture project has no official name or codeword, so I 
have used the name NONVAX in this report. 

The hardware ""and software products that are being designed can be 
briefly described as "a non-VAX architecture that will.be an upward 
extension of the VAX/VMS family". The initial product will be 
oriented toward the scientific/technical computational market. The 
operating system will have a compatible file system, network, and user 
interface with VMS. NONVAX systems will also be able to be clustered 
with VAX/VMS systems. 



DECwest Trip Report: Technical Summary Page 2 

GENERAL 

The system should provide higher-level languages that are compatible 
with VAX. Key languages for the PCS product are FORTRAN, and perhaps 
C or Pascal. BLISS will be needed for porting VMS layered products 
and a new systems implementation language will be used for w ting 
most of the NONVAX operating system. We expect that there will be 
strong demand for the other VMS languages, and that all will be ported 
soon after FCS. 

In general, Dave expects that DECwest will produce: 

1. A NONVAX hardware emulator and the first NONVAX product 

2. Operating system 

3. File system and RMS 

4. DECnet 

5. Linker and some utilities 

6. System implementation language, most likely based on the ELN 
Pascal language and compiler 

There was agreement that SpitBrook would produce: 

1. FORTRAN compiler 

2. BLISS compiler to be used in porting various VMS layered 
products to NONVAX. While the operating system will not use 
BLISS, it will be an important implementation language for 
many products. 

3. RTL 

4. DEBUG 

5. Additional compilers and layered products for future releases 



2 SCHEDULE 

The project has no schedule yet, but the following dates and 
timescales are being discussed: 

o On the order of 3 years to FCS, 2.5 years to Field Test 

o July 1985 - publish NONVAX architecture SRM, first draft 

o Summer 1985 - review/ revise/ approve SRM 

o Fall 1985 - begin detailed design of operating system. This 
effort is expected to proceed like the original VMS design. 
The first 6 months will be devoted to design of the operating 
system and documenting that design in a Working Design 
Document . 

o March 1986 - First version of Implementation Language 
cross-compiler available to operating system group. 



DECwest Trip Report: Technical Summary Page 3 

HARDWARE ARCHITECTURE 

3 HARDWARE ARCHITECTURE 

The NONVAX hardware architecture team was meeting at DECwest and Don 
MacLaren and I spent one day talking with them about various language 
issues. The hardware architecture team consists of: 

o Dave Cutler 

o Dileep Bhandarkar (VAX architecture, LTN) 

o Wayne Cardoza (VMS) 

o Dave Orbits (SAFE, MRO) 

o Rich Witek (Chips, HLO) 

The hardware architecture team is making good progress. They expect 
to produce a complete draft of the SRM by late June or early July. 
The draft SRM will be widely distributed and reviewed within DEC, just 
as the original VAX SRM. 

Attachment 2 is the architecture team's statement of goals and 
constraints. 



3.1 Architecture Characteristics 

This section enumerates a number of key characteristics of the 
hardware architecture that is being defined and comments on some of 
the software implications. 

o NONVAX has a simple instruction set architecture that is 
intended to facilitate high-speed implementations and 
pipelining. 

Each instruction is 32 bits long and there are a small number 
of instruction formats. 

o NONVAX supports VAX datatypes, memory layouts, and byte 
addressability. These are the key attributes required in 
order to produce high-fidelity VAX- compatible compilers for 
NONVAX. The floating point format is the same scrambled VAX 
representation, and bytes and bits within a longword are 
numbered and addressed like a VAX. 

o NONVAX has 64 registers, each is 64 bits wide. The machine 
is a Load/Store machine. That is, only Load and Store 
instructions can reference memory operands. All arithmetic 
and N logical operations are performed on values contained in 
the registers. In short, it looks a good deal like a CDC 
6600. 

The current NONVAX design is strongly influenced by the SAFE 
design that has been done in Marlboro. The NONVAX is much 
more like SAFE than RISC machines such as TITAN or HR32. 



DECwest Trip Report: Technical Summary P a 9 e 4 

HARDWARE ARCHITECTURE 

o The major departure from VAX datatypes is that NONVAX 
addresses are 48 bits. The standard semiconductor metrics 
(i.e. one address bit every 2 years) indicate that. VAX. will 
run out of physical and virtual address bits sometime in the 
1990' s. The architecture team is convinced that NONVAX must 
provide more address bits. 

The 48-bit address space is "flat". That is there are no 
visible segments, and address arithmetic propagates carries 
through 48 bits (across page and segment boundaries). 

The design of the page tables and the operating system is 
intended to support very large sparse address spaces at a 
very low cost in physical memory for segment and page tables. 
For example, it is deemed reasonable to allocate 32Mb for a 
task stack and to isolate that stack by a 32Mb guard region 
of unallocated memory. 

Larger addresses will be the most painful problem in 
providing VAX-compatible higher level languages. Data 
structures that contain pointers will have to allow a larger- 
field, and so the structure layouts cannot be identical 
between VAX and NONVAX. In languages that have real pointer 
types (e.g. Ada, Pascal, PL/I), most of this can be hidden 
bv the compiler. FORTRAN programmers that manipulate 
pointers using the %LOC function and 32-bit integers won t be 
so fortunate . 

o The page size will be much larger than VAX, probably at least 
16Kb. There is also talk of having the architecture specify 
a minimum (16Kb) and maximum (512Kb) page size rather than a 
single fixed page size. In order to port images between 
different implementations, the software would have to make 
the smallest unit of virtual allocation and protection be the 
maximum page size (512Kb) . 

The larger page size is desirable because it will provide 
more untranslated address bits to be used by direct-map 
caches, and there will be less overhead for managing pages in 
the operating system. The larger page size is undesirable 
because the allocation granularity is larger and there will 
be more breakage when allocating small chunks that have 
different protection attributes. 

o The % NONVAX hardware does not support unaligned data access. 
That is, INTEGER*4 quantities must be aligned on a longword 
boundary, REAL*8 on a quadword boundary, etc. -The NONVAX 
operating system will handle alignment faults and quietly fix 
up non-aligned references, much as MicroVAX emulates string 
and decimal instructions. However, this emualation will 
incur a substantial performance penalty; on the order of 100 
times slower than a properly aligned reference. Because the 
performance hit is so large, we expect that compilers will 
provide an optional "natural boundary" alignment when laying 



DECwest Trip Report: Technical Summary Pa 9 e 5 

HARDWARE ARCHITECTURE 

out records and data structures. The compilers will also 
provide the VAX "pack to the nearest byte" layout. Both VAX 
and NONVAX compilers should provide both layouts, and should 
provide a reporting option to identify misaligned items. 

o NONVAX is a "base register" machine. Since all instructions 
are 32 bits long and addresses are 48 bits long, you can t 
include a full address in a single instruction. Thus unlike 
the PDP-10, PDP-11, and VAX you must use base-displacement 
addressing to reference memory operands. As another 
consequence, the calling conventions define the format of a 
linkage section and when you call a procedure you must 
provide a pointer to the called procedure's linkage section 
as an argument. 

Load/store instructions have a signed 14-bit displacement 
field, so the displacement range is +-8K bytes from the base 
address. Jump-class instructions (JSR, conditional and 
unconditional branches) have a 20-bit displacement in 
longword units which provides +-2Mb displacements. Compilers 
won't need Jump/Branch resolution since 2Mb of code in a 
single object module seems like plenty (at least for the 
first release) . 

o There are Load/Store instructions to load bytes, words, 
longwords, and quadwords. For short quantities, you can 
sign-extend or zero-extend as you load the value into a 
64-bit register. All integer and logical operations operate 
on 64-bit register values. There are convert instructions to 
convert a 64-bit value to a byte/word/longword and check for 
overflow. 

o The instruction set is much simpler than the VAX. This means 
that the following classes of VAX instructions are NOT 
provided : 

There are no string instructions. 

- There are no packed decimal instructions. 

- There are no variable bitfield instructions. Field 
extraction and insertion are performed by loading a 
quadword into a register and using SHIFT, ROTATE, AND, 
and OR instructions. Accessing a bit within a packed bit 
array will involve separating the bit index into a byte 

^offset and bit within byte, fetching the byte, and then 
shifting and masking to isolate the bit. 

- in the current proposal, the only floating type with full 
hardware support is G- floating. There are CVTFG and 
CVTGF instructions so you can do an F-floatmg VAX 
operation by converting both F operands to G, performing 
a G operation specifying chopping, and converting the 

result back to F to get the correctly rounded VAX F-float 



DECwest Trip Report: Technical Summary Pa 9 e 6 

HARDWARE ARCHITECTURE 

result. Note that you must perform these converts after 
EVERY F operation in order to get the same results that 
VAX does. If you keep temps in G format, you get 
floating results like the C language where all 
intermediate calculations are done in double precision. 

There has been an active debate about providing more 
support for F-floating, a full set of F-floating 
operations. It does not seem desirable to have a machine 
where single precision is slower than double precision. 

- There is no hardware support for D-floating or 
H-floating . 

There is concern about whether customers will accept a 
NONVAX that does not efficiently support D-floatmg; 
there was a lot of resistance to the G-only MicroVAX I. 

initial estimates suggest that NONVAX software can 
probably perform H-floating operations in times that are 
similar to the VAX warm-microcode approach on machines 
like VENUS and Nautilus. 

We expect that the software will provide a CISRTL (Complex 
instruction Set RTL) of highly tuned low-overhead subroutines 
to perform operations equivalent to many of the missing VAX 
instructions (strings, decimal, D-float, H-float, etc). The 
architecture team expects that these "micro code in macro 
code" routines should provide performance on string 
operations that is comparable to what VAX microcode delivers. 

o NONVAX does not have exception enables (e.g. integer 
overflow) in the Processor Status word. Rather, enables and 
rounding mode are encoded directly into the instructions. 
Thus there are two integer add instructions: ADD (no 
overflow signaled) and ADDV (add and check for overflow), and 
similarly for other instructions. 

All arithmetic exceptions are faults; the PC is backed up to 
the faulting instruction and no result is stored. 

o NONVAX does not have condition codes. The compare 
instructions produce a boolean result (0 or 1) in a general 
register, and you use a branch on low bit instruction to 
actually branch on the result of the comparison. This 
improves branching performance because the compiler can 
schedule the comparison so that the boolean; result is 
available when the branch is executed. There is also a set 
of (integer) compare against and jump instructions. 

o NONVAX provides Execute-only protection on pages. Thus code 
generators cannot put literals in the code section. 



DECwest Trip Report: Technical Summary P a 9 e 7 

HARDWARE ARCHITECTURE 

o NONVAX provides a BPT instruction, but there is no T-bit. In 
order to execute an instruction that has been replaced by a 
breakpoint, the debugger will have to decode and interpret 
the instruction. The simple fixed- format instruction set 
should make this a reasonable approach. 

o The hardware is designed to support symmetric 

multi-processing and the operating system will support 

multiple threads of execution within a single process 

(address space). The Run-Time Library will have to be fully 

reentrant; AST-reentrancy is not sufficient. All compilers 

should (at least optionally) generate fully reentrant code 
and calling sequences. 



4 SOFTWARE ARCHITECTURE 

Don MacLaren and I enumerated a number of specifications that will 

define the software architecture. These cover familiar topics from 

VAX such as data types, calling conventions, run- time environment 
structure, object language, debug symbol table, etc. 

We expect that the software architecture process for NONVAX will be 
much like the VAXS/VAXL process. Initial proposals for new designs 
will be prepared by small working groups and reviewed by a larger 
group representing many languages and products. Stable specifications 
will be updated by an ECO process. We plan to collect all 
specifications for the software architecture in a multi-volume 
notebook set. An outline for the notebook set is included as 
Attachment 1 of this trip report. 

We worked on calling conventions in detail and came up with Rev of 
the calling conventions. We will be presenting this proposal to 
groups in DECwest and SpitBrook and then writing up a first draft. 

We discussed goals and constraints for VAX compatibility. Our general 
coal is that user programs written in higher-level languages such as 
Pascal or FORTRAN shSuld run without change on the NONVAX and produce 
similar results. In some cases it may be necessary to make changes in 
programs. For example, a FORTRAN program that manipulates addresses 
in INTEGER*4 variables won't work on a machine with 48-bit pointers. 
It should be possible to modify such programs so that the modified 
source can be, compiled to work correctly on both machines. 

NONVAX compilers will use the same set of default types that VAX 
compilers do. That is, in FORTRAN or Pascal, "integer" . will mean a 
32-bit signed longword, "real" will mean 32-bit F-floating, and 
"double" will mean 64-bit floating (G-floating or D-floating depending 
on the compiler's /G_FLOATING switch). Since INTEGER'S will be an 
important type on NONVAX, we expect that we will also have to provide 
INTEGER*8 in VAX compilers. 



DECwest Trip Report: Technical Summary Pa 9 e 8 

SOFTWARE ARCHITECTURE 

We expect that VAX and NONVAX will coexist ( in clusters and networks) 
for a relatively long time, so it is very important to do a good job 
on compatibility issues. 



5 CALLING STANDARD 

The NONVAX calling standard must preserve a number of key attributes 
of the VAX calling standard, including: 

o Mixed language programming. 

o Use of procedure calls as the primary interface to all 
services and subsystems. 

o NONVAX must preserve the "programmer's view" of procedure 
calls as seen on VAX from the perspective of a higher level 
language . 

o NONVAX will provide by value, by reference, and by descriptor 
mechanisms for argument transmission and the caller will have 
the same degree of control as on VAX. 

o NONVAX will provide a condition handling mechanism that is 
functionally equivalent to VAX. 

The NONVAX calling standard will add a number of new attributes: 

o There will be greater emphasis on performance of procedure 
calls. 

o NONVAX will provide "lighweight" procedures whose performance 
is similar to JSB linkage on VAX. Lightweight procedures 
will be invoked using the standard calling sequence, so this 
is purely an optimization performed by the compiler based on 
the complexity and requirements of the called procedure. 

o The standard NONVAX procedure call will pass the first 4 
arguments in registers; procedures with 4 or fewer arguments 
won't use an argument list in memory. 

o All descriptor formats must be modified to accomodate 48-bit 
addresses. Some improvements in descriptor design are 
planned. For example, it seems desirable to provide only 
non-contiguous array descriptors; this will improve 
communication between FORTRAN and Pascal or PL/I v 

o All parametric procedures will be passed as bound procedure 
values rather than as entry point addresses. 

o The NONVAX calling standard must make effective use of the 
much larger number of registers. Registers R0-R15 will be 
scratch registers and need not be preserved. Interprocedural 



DECwest Trip Report: Technical Summary P a 9 e 9 

CALLING STANDARD 

analysis (in a mixed language environment) will tailor 
linkages to reduce call overhead. 

I will be distributing a draft of the NONVAX calling standard for 
review and comment. 



6 DEVELOPING THE SOFTWARE ARCHITECTURE 

Don MacLaren will be visiting SpitBrook June 11-14 to continue work on 
the software architecture. I will serve as host and will organize a 
number of technical meetings. The primary topics for discussion are: 

1. NONVAX software architecture 

A general discussion of the overall software architecture, 
the specifications that need to be written, and architectural 
process. 

2. NONVAX calling standard 

Discussion and review of the first draft of the NONVAX 
calling standard. 

3. System Implementation Language (SIL) requirements 

As noted above, current thinking is that the NONVAX systems 
implementation language will be based on the ELN Pascal 
compiler and language. The operating system group has a goal 
of writing "almost all" of the operating system in a 
higher-level language. They estimate that there will be luK 
to 20K of very low level kernel code written in Macro, and 
all the rest in the SIL. 

All of the RTL, including the math library, will be written / ? 
in the SIL. The SIL must provide facilities for exploiting ^ 
all features of the hardware architecture. J 

The SIL effort has a number of constraints, with schedule 
being the most pressing. With less than a year to develop an 
initial version, we can't plan to design and implement the 
ultimate SIL. 

The goal of this session is to have art open but disciplined 

brainstorming session on the requirements for a new systems 

implementation language. All participants must agree to 

avoid language chauvinism and religious fanaticism and focus 
on requirements. 

We assume there will be two primary implementation languages; 
BLISS-64 and a new NONVAX implementation language derived 
from ELN Pascal. The focus of this discussion will be 
requirements for the new language; we may also discuss BLISS 



DECwest Trip Report: Technical Summary Page 10 

DEVELOPING THE SOFTWARE ARCHITECTURE 

extensions to support VAX-NONVAX portability. 

4. DEBUG and PCA 

Symbol table requirements and design for DEBUG and PCA. 

5. RTL and multitasking 

A goal of the NONVAX software architecture is to provide 
support for multiple threads of execution within a single 
process (address space). This will provide facilities like 
tasking in Ada and VAXELN. 



tend of RBG066.RNO] 



Page 1 

SOFTWARE ARCHICTECTURE SPECIFICATIONS RELATED TO LANGUAGES 
Don MacLaren — 20-May-1985 

This is an initial outline of specifications needed in this area with 
commentary on the purpose of some of them. It's based on notes from a 
discussion with Rich Grove, but I have added some additional material. 

We have divided the specs into three "books", with the first book 
beinq the one of current interest. There is overlap between the 
material included here and what one finds in operating system 
documentation . 

NOTE: This is a preliminary outline of a set of working documents. 
Nothing is approved; everything is subject to change. 



1 THE EXECUTION ENVIRONMENT 

This book, together with the hardware architecture book, describes the 
runtime environment in which compiled programs execute — excluding 
operating system characteristics that have little effect on compiled 
code. Because the instruction set contains no high-level instructions 
such as the VAX call, some of the material here would fall in the VAX 
hardware manual . 



1.1 Data Types 

This section describes all data types recognized in the hardware 
architecture. Recognition doesn't imply comprehensive support. 
However it does mean that treatment of the data type will be covered 
in the calling standard and that the debugger will understand the 
type. 

Alignment and structure mapping are covered. 



1.2 Stack Structure And Register Conventions 

Covers stack frames, LP, SP, FP, exception handling and unwinding. 

1.3 The Calling Standard *■>:_ 

1. Linkage conventions including linkage section related to calling. 

2. Argument lists: registers vs. memory, optional, variable-length, 
etc . 



Page 2 

3. Standard and Variant Argument Passing Conventions By Data Type. 

4. By-value arguments -- a true thorn bush for those that don't fit 
in a register. 

5. Descriptors. 

6. Returning Function Values. 



1.4 Tasking 

1 . 5 AST ' s 

in particular, an explanation of the best ways to make code AST 
reentrant or non-AST- interruptible. 



1.6 Status Codes And Error Messages 

This to include a more contemporary fao capability 



1.7 CIS Specifications 

soecifications for standard complex instruction sequences. This 
covers sequences for things like MOVC, but it is not restricted to 
analouges of the VAX instructions. 

How such sequences fit into the system must also be explained. 



1.8 Miscellaneous issues 

1. One-time initilization in programs. 

2. Same thing in tasks? 

3. Effect of hardware exception treatment when reflected to the level 
of a topical language. 



1.9 Compatibility 

Significant differences from VAX/VMS and how to deal with them. 



Page 3 



2 COMPILER INTERFACES 

This book describes various substantial structures that "J^ft 
compilers' interfaces to other system tools. The title was chosen in 
desperation. 

The architectural specifications in this book are open; they will be 
made available to users. 

1. The Object Language. 

2. Debug Symbol Table. 

3. CDD interface. 

4. Librarian interface. 

5. Diagnostics Output Records. This is what the language-sensitive 
editors read to help a user correct his source program, 

6. Definition Modules. One of these modules contains definitions of 
data structures and procedure entries. The form is acceptable to 
all the compilers. 

7. information Output Records. These give additional information 
about a compilation, its usage of symbols, etc. 

ThPnici 6 and 7 are new, at least relative to our VMS environment. 
Tne'r "elusion Is aimed at supporting improved programming 
environments. 



3 INTERNAL COMPILER ARCHITECTURE 

This book describes the common structure of compilers **«£ u fJ the 
common back end. It is the basis for the development of the initial 
set of product compilers. 

This is not likely to be a public document.